Whiteline: Alpha

home *** CD-ROM | disk | FTP | other *** search

/ Whiteline: Alpha / Whiteline Alpha.iso / progtool / pascal / o_gem / doku / doku.txt < prev next >

Wrap

Text File | 1994-09-22 | 49.7 KB | 1,403 lines

WICHTIG: Diese Doku wurde aus einem TEX-File erzeugt. Leider hat dabei die Darstellungsqualität etwas gelitten :-), ich werde mich aber bei zukünftigen Versionen um ein besseres optisches Outfit kümmern. Aber es gibt ja mittlerweile auch das g e d r u c k t e Handbuch... Das ObjectGEM Programmierhandbuch Version 1.17 Das vorliegende Handbuch ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Jegliche Vervielfältigung auf fotografischem, mechanischem, elektronischem oder anderem Wege bedarf der schriftlichen Genehmigung durch den Autor. Die in diesem Buch erwähnten Markenzeichen, Firmennamen, Software- und Hardwareprodukte sind nicht gesondert gekennzeichnet, unterliegen aber trotzdem dem jeweiligen gesetzlichen Schutz. ObjectGEM und Dokumentation Copyright 1992-94 Thomas Much "ObjectGEM in Beispielen" Copyright 1994 Jan Pilgenröder @ AC3 Auf dem Atari ST/STE/TT/Falcon bricht ein neues Zeitalter des Software-Engineering an! Aber sehen und lesen Sie selbst... ObjectGEM ist eine Sammlung von Units für PurePascal, mit der komplexe GEM-Programme wesentlich einfacher als bisher erstellt werden können. Mit ObjectGEM wird es auch möglich, daß alle Programme, die z.Z. auf GEM verzichten, weil sie z.B. nur irgendwelche Statusausgaben machen, korrekt und mit nur geringem Mehraufwand unter GEM implementiert werden. Außerdem können Dialoge mit allen State-of-the-Art-Buttons etc. versehen werden, der Rest (Verwaltung, Redraw, Auswertung) geschieht dann automatisch. Wer allerdings unbedingt möchte, kann sich auch bis zur untersten Stufe der GEM-Programmierung mit einklinken - OOP macht's möglich! ObjectGEM-Programme sind im Vergleich zu anderen Bibliotheken recht groß. Dabei muß man aber die Tatsache bedenken, daß objektorientierte Programmierung eigentlich noch nie auf den Speicherbedarf geachtet hat (das liegt in der Natur der Sache...). Dafür ist der Funktionsumfang aber beträchtlich, denn selbst das kleinste ObjectGEM-Programm weiß bereits, wie ein komplettes GEM-Fenster zu funktionieren hat. Außerdem kommt es in der heutigen Zeit mehr darauf an, in möglichst kurzer Zeit Programme zu schreiben, die leicht zu bedienen sind, sicher laufen und gut erweitert bzw. gewartet werden können; der Speicherbedarf tritt dabei zunehmend in den Hintergrund. Trotzdem belegt ObjectGEM immer nur soviel Speicher wie gerade nötig, da so ziemlich alles dynamisch verwaltet wird. Und außerdem: Wer einmal mit ObjectGEM angefangen hat, wird bestimmt nicht so schnell wieder damit aufhören! ObjectGEM ist an neuere AES-Versionen (4.x), MultiTOS und Mag!C angepaßt, d.h. es ist z.B. möglich, Dialoge im Hintergrund zu bedienen (Buttons anklicken etc.)! Für X/Unix-Benutzer steht sogar ein entsprechender Mausposition-abhängiger Eingabemodus zur Verfügung. In Vorbereitung ist außerdem der GEM-Wizard, mit dem ObjectGEM-Programme mit ein paar Mausklicks generiert werden können! für Atari ST, STE, TT, Falcon mit PurePascal, mind. 1 MB RAM und Festplatte Shareware, daher nur DM 50,- Registrierungsgebühr (DM 60,- incl. Handbuch) incl. aller Quelltexte autom. Dialogabarbeitung (optional auch "von Hand") ebenso einfache Behandlung von Fenstern und Menüs Fensterdialoge (auch im Hintergrund bedienbar!) Fenster-Toolbars und -Menüs unter allen TOS-Versionen automatische XAcc- und AV-Protokoll-Behandlung Iconification (auch ICFS), Drag&Drop kontextsensitive Bubble-Help (s. Mac System 7) ausführliche Online-Hilfe innerhalb der PP-Shell Und wen es interessiert: Ein Test von ObjectGEM 1.00 findet sich im ST-Magazin 7/93, S.22 ff.! Nun aber genug der Vorrede, viel Spaß und Erfolg mit ObjectGEM! ObjectGEM ist ein Shareware-Produkt. Das Programmpaket darf beliebig weitergegeben werden, sofern die Units (d.h. die Quelltexte mit den dazugehörigen Dateien (Beispielprogramme, Dokumentation etc.) zusammen weitergegeben werden. Jeder kann dann in Ruhe ein bißchen mit ObjectGEM herumprobieren. Wer allerdings länger mit ObjectGEM programmiert (egal, ob die Programme veröffentlicht werden oder nicht), muß sich registrieren lassen. Die Registrierung kostet DM 50,- (bzw. DM 60,- mit Handbuch). Das ist - im Vergleich zu kommerziell angebotenen Bibliotheken - nicht sehr viel. Trotzdem dürfen Programme, die mit einer registrierten ObjectGEM-Version erstellt wurden, ohne etwaige Lizenzgebühren weitergegeben, verkauft etc. werden. Überweisen Sie dazu DM 50,- (bzw. DM 60,-) auf das Konto: Thomas Much, Sparkasse Karlsruhe, Kto. 935 30 95, BLZ 660 501 01 (Ihre Adresse nicht vergessen!) oder schicken sie einen Verrechnungsscheck über diesen Betrag an: Softdesign Computer Software c/o Thomas Much, Gerwigstraße 46, 76131 Karlsruhe Sie können den Betrag auch auf folgendes Konto überweisen: Thomas Much, Postgiroamt Karlsruhe, Kto. 314881-753, BLZ 660 100 75 Dann muß allerdings mit z.Z. bis zu vier Wochen Wartezeit gerechnet werden (die Post...). Wichtig: Wenn Sie einen Scheck aus dem Ausland schicken und diesen nicht in DM ausstellen, berechnen Sie bitte DM 8,- extra! Wenn Sie aus dem Ausland überweisen, machen Sie dies bitte so, daß der Empfänger keine zusätzlichen Gebühren zahlen muß. Danke! Sie erhalten dann umgehend die aktuelle Version - es sei denn, Sie geben bei Ihrer Registrierung die Versionsnummer der Ihnen vorliegenden ObjectGEM-Unit an; ist diese Version noch aktuell, erhalten Sie erst dann eine Diskette zugeschickt, wenn eine neue Version veröffentlicht wird (wer also auf jeden Fall und sofort eine Disk bekommen möchte, sollte bei seiner Registrierung keine Versionsnummer angeben...). Außerdem haben Sie dann die Möglichkeit, jederzeit mit einer formatierten 3,5" Diskette und einem frankierten und addressierten Rückumschlag ein evtl. vorhandenes ObjectGEM-Update direkt beim Autor (Adresse s.u.) zu bekommen. Kosten wird dies nur dann etwas, wenn der Registrierpreis steigen sollte. Die neueste Version ist aber auch per Modem über die Maus-Mailboxen KA, AC3 und HL zu beziehen (und vermutlich auch in einigen anderen Mailboxen erhältlich). Der Vertrieb über PD-Versender, Mailboxen, Diskettenzeitschriften etc. ist erlaubt und ausdrücklich erwünscht! Dann möge man sich aber bitte um die aktuelle Version bemühen. Achtung: Zusammen mit ObjectGEM darf der VDI-Enhancer weitergegeben werden. PD-Versender müssen vor der Weitergabe aber erst prüfen, ob sie die entsprechenden Bedingungen erfüllen. Ist dies nicht der Fall, müssen sie den Enhancer aus dem ObjectGEM-Paket entfernen! Da ObjectGEM mit dem vollständigen Quelltext ausgeliefert wird, hat die Shareware-Version keinerlei Einschränkungen mehr. Ich hoffe aber trotzdem, daß sich dies nicht negativ auf die Registrierungsmoral auswirkt - ich würde mich freuen, wenn alle diejenigen, die sich bisher wegen PP-Kompatibilitätsproblemen oder dem fehlenden Quelltext nicht registrieren lassen wollten (dies wurde mir von sehr vielen Leuten mitgeteilt), nun die Weiterentwicklung finanziell unterstützen würden. Die registrierte Vollversion von ObjectGEM ist incl. Handbuch für DM 60,- auch bei whiteline erhältlich: whiteline Konzeption, delta labs software B. Artz & T. Kohl, Rembrandtstraße 1, 42329 Wuppertal Tel. & Fax (0202) 734361 Kontakt im MausNet: Tom Kohl @ W Wichtig: Wer ObjectGEM mehr als nur zu Testzwecken einsetzt und sich nicht registrieren läßt, verwendet eine Raubkopie!!! Die Installation sollte keine großen Probleme bereiten. Kopieren Sie einfach alle Pascal-Dateien (*.PAS) in Ihr Unit-Verzeichnis (dort, wo auch TOS.PPU, GEM.PPU etc. stehen) bzw. in das Verzeichnis, in dem Sie sonst die Quelltexte Ihrer Units ablegen, und GOBJECTS.HLP in das Help-Verzeichnis (dort sollten auch PP.HLP etc. zu finden sein). Fertig! Die Units werden nun wie gewohnt mit der -Klausel eingebunden. Wenn Sie Ihr erstes ObjectGEM-Programm compilieren, werden dann zunächst alle ObjectGem- Units erzeugt (das dauert etwas). Um in die Übersicht der Online-Hilfe zu gelangen, suchen Sie unter "Help - Help..." (oder mit ) am besten nach "ObjectGEM" oder "GObjects". Ansonsten bringen Sie den Cursor auf eine fragliche Konstante oder Methode und drücken , woraufhin eine Erklärung dazu erscheinen sollte. Dabei ist es egal, ob Sie z.B. nach "Style" oder "Attr.Style" suchen - wenn es mehrere Möglichkeiten gibt, erhalten Sie ein Auswahlmenü. Wenn Sie meinen, einen Fehler in der Online-Hilfe gefunden zu haben (falscher oder fehlender Verweis, falsche oder nicht ausreichende Beschreibung), setzen Sie sich bitte mit mir (dem Autor) in Verbindung. Danke. Falls Probleme mit oder Fragen zu ObjectGEM auftauchen sollten, können Sie dies dem Autor direkt mitteilen. Bitte benutzen Sie den telefonischen Weg nur in dringend Fällen oder bei kurzen Fragen. Wenn Sie ausführlichere Antworten wünschen, schicken Sie bitten einen Brief mit folgenden zusätzlichen Angaben: ObjectGEM-Version PurePascal-Version bzw. -Datum Rechner, Speicherausbau, Grafikkarte TOS-Version (Übrigens: Da ObjectGEM Shareware ist, ist bei solchen Anfragen gegen beiliegendes Rückporto nichts einzuwenden...) [3mm] Softdesign Computer Software c/o Thomas Much, Gerwigstraße 46, 76131 Karlsruhe Tel.: (0721) 62 28 41 (am besten Mo-So zwischen 19 und 22 Uhr) [3mm] Am liebsten werden natürlich Anfragen von registrierten ObjectGEM-Anwendern beantwortet, aber falls grundsätzliche Fragen bestehen, haben auch potentielle Käufer eine Chance (da Sie dies aber offensichtlich in gedruckter Form lesen, werden Sie höchstwahrscheinlich auch registriert sein). Als registrierter Anwender haben Sie außerdem die Möglichkeit, Updates (die alle paar Wochen erscheinen) durch Einsenden einer formatierten 3,5"-Diskette und eines frankierten und addressierten Rückumschlags zu erhalten. Wenn Sie dies "präventiv" machen (d.h. am besten sofort wieder nach Erhalt eines Updates), bekommen Sie das nächste Update zugeschickt, sobald es verfügbar ist. Und wenn Sie sowieso schon dabei sind, eine Update-Diskette einzuschicken, wäre es nett, wenn Sie dann auch das Anwenderprofil ausdrucken (Datei REGISTR.TXT), ausfüllen und mitschicken könnten (besten Dank im vorraus!). Wer ein Modem besitzt, kann sich natürlich die neuesten Versionen selbst saugen (und kann damit auf die Diskette verzichten). Neue Versionen sind zuerst in den Maus-Mailboxen KA und AC3 sowie in der ASH-Mailbox verfügbar. Das Anwenderprofil kann dann auch an die folgende EMail-Adresse geschickt werden: [3mm] MausNet: Thomas Much @ KA2oder [3mm] Internet: UK48@ibm3090.rz.uni-karlsruhe.de [4mm] Maus KA, (0721) 358887, kein Gastdownload von 18.00 bis 21.45 Maus AC3, (0241) 54540, kein Gastdownload! ASH-Mailbox, (06221) 303671 (dort jeweils die Datei GOBJ_1xx.ZIP im öffentlichen Programmteil) [3mm] Außerdem ist ObjectGEM auf folgenden ftp-Sites zu finden: ftp.uni-muenster.de /pub/atari/Programming/gobj_1xx.zip ftp.uni-kl.de /pub/atari/programming/gobj_1xx.zip Diese Einführung soll zeigen, wie man mit ObjectGEM schnell und einfach eigene GEM-Programme schreiben kann. Ich gehe dabei nicht allzusehr in die Tiefe und ich werde auch nicht jeden einzelnen Befehl beschreiben (wer näheres zu den einzelnen Befehlen wissen will, möge einen Blick in die Online-Hilfe werfen - die Online-Hilfe ist wirklich gut und beschreibt jeden Befehl in aller Ausführlichkeit. Stattdessen werde ich versuchen, zu zeigen, wie man die einzelnen Befehle zusammenfügt. Diejenigen, die mit den Grundbegriffen der GEM-Programmierung und der objektorientierten Programmierung nicht vertraut sind, sollten sich jetzt erst einmal schlau machen - diese Einführung kann die Grundlagen nicht liefern. Das PurePascal-Handbuch sollte aber ausreichen, um das nötige Wissen zu vermitteln. Es gibt einige Elemente, die in jedem ObjectGEM-Programm vorkommen müssen. Schauen wir uns dazu mal das kleinstmögliche Programm an: PROGRAM Minimal; USES OWindows; VAR MyApplication: TApplication; BEGIN MyApplication.Init('MINI','Minimal'); MyApplication.Run; MyApplication.Done END. Zunächstmal müssen wir die Unit OWindows benutzen. In dieser Unit stehen die wichtigsten Objekte und Methoden (eine Liste findet sich in der Online-Hilfe). Dann müssen wir unser Applikations-Objekt, das für die Initialisierung und den Message-Loop des Programms zuständig ist, anlegen. Wir definieren eine Variable MyApplication als Object vom Typ TApplication und initialisieren diese Instanz von TApplication mit . Dabei ist 'MINI' der Cookie, der beim Programmstart im Cookie-Jar eingetragen wird, und 'Minimal' der Name der Applikation. kümmert sich dann um die Routienearbeit, während das Programm läuft, und beendet das Programm. Dieses Minimal-Programm kann sogar schon einiges. Es baut ein Fenster auf und verwaltet es - man kann also mit diesem Fenster alles machen, was man so von Fenstern gewohnt ist. Das Programm wird beendet, wenn man drückt oder das Fenster schließt. Mit dem Fenster aus MINIMAL.PAS kann man allerdings noch nicht viel Sinnvolles anfangen, und manchmal möchte man in seinem Programm überhaupt kein Fenster (oder kein Haupt-Fenster) haben. Wenn wir an diesem Fenster etwas ändern wollen, müssen wir dazu die Methode, die es anlegt, überschreiben. Diese Methode heißt und ist eine Methode des Objektes TApplication; sie wird innerhalb von TApplication.Init aufgerufen. Dazu legen wir uns ein von TApplication abgeleitetes Objekt an, indem wir die Methode InitMainWindow neu schreiben. Das ganze sieht dann so aus: PROGRAMM Minimal; TYPE PMyApplication = ^TMyApplication; TMyApplication = OBJECT(TApplication) PROCEDURE InitMainWindow; VIRTUAL; END; VAR MyApplication: TMyApplication; PROCEDURE TMyApplication.InitMainWindow; BEGIN END; BEGIN MyApplication.Init('MINI','Minimal'); MyApplication.Run; MyApplication.Done END. Anstatt ein Fenster anzulegen, macht unser neues InitMainWindow einfach gar nichts. Dialoge und Alert-Boxen kommen nun wirklich in fast jedem GEM-Programm vor, deshalb möchte ich auch gleich damit anfangen. Dazu dann auch gleich wieder ein Beispiel: PROGRAM Kleines; USES OWindows,OTypes,ODialogs; I KLEINES.I TYPE TMyApplication = OBJECT(TApplication) PROCEDURE InitInstance; VIRTUAL; PROCEDURE InitMainWindow; VIRTUAL; END; PInfoMenu = ^TInfoMenu; TInfoMenu = OBJECT(TKeyMenu) PROCEDURE Work; VIRTUAL; END; POpenDialog = ^TOpenDialog; TOpenDialog = OBJECT(TKeyMenu) PROCEDURE Work; VIRTUAL; END; PMyDialog = ^TMyDialog; TMyDialog = OBJECT(TDialog) FUNCTION OK: BOOLEAN; VIRTUAL; FUNCTION Cancel: BOOLEAN; VIRTUAL; END; VAR MyApplication: TMyApplication; Buffer : RECORD Kette: STRING[21]; O1,O2: INTEGER END; PROCEDURE TMyApplication.InitInstance; BEGIN LoadResource('KLEINES.RSC',''); LoadMenu(main_menu); NEW(PInfoMenu,Init(@SELF,K_Ctrl,Ctrl_I, menu_info,desk_menu)); NEW(POpenDialog,Init(@SELF,K_Ctrl,Ctrl_D, menu_open_dialog,file_menu)); INHERITED InitInstance; SetQuit(menu_quit,file_menu) END; PROCEDURE TMyApplication.InitMainWindow; BEGIN END; PROCEDURE TInfoMenu.Work; BEGIN IF ADialog=NIL THEN NEW(ADialog,Init(NIL,'Über KLEINES', info_dial)); IF ADialog <> NIL THEN ADialog^.MakeWindow END; PROCEDURE TOpenDialog.Work; BEGIN IF ADialog=NIL THEN BEGIN ADialog:=NEW(PMyDialog,Init(NIL, 'KLEINES Übungsprogramm', main_dial)); IF ADialog<>NIL THEN BEGIN NEW(PButton,Init(ADialog,md_ok,id_ok, TRUE,'Zeigt Eingaben in einer Alertbox an und beendet das Programm.')); NEW(PButton,Init(ADialog,md_cancel,id_cancel, TRUE,'Beendet Programm, ohne Daten Anzuzeigen.')); NEW(PEdit,Init(ADialog,md_edit,21, 'Hier kann Text eingegeben werden.')); NEW(PGroupBox,Init(ADialog,md_option_box, 'Optionen','In dieser Box befinden sich zwei RadioButtons')); NEW(PRadioButton,Init(ADialog,md_option1,TRUE, 'Die erste Option')); NEW(PRadioButton,Init(ADialog,md_option2,TRUE, 'Die zweite Option')); ADialog^.TransferBuffer:=@Buffer END END; IF ADialog<>NIL THEN ADialog^.MakeWindow END; FUNCTION TMyDialog.OK: BOOLEAN; VAR Valid : BOOLEAN; Ausgabe: STRING; BEGIN Valid:=INHERITED OK; IF Valid=TRUE THEN BEGIN Ausgabe:='In die Editzeile wurde "+Buffer.Kette +' eingegeben. Es wurde der Radio button "; IF Buffer.O1=bf_checked THEN Ausgabe:=Ausgabe+'1' ELSE Ausgabe:=Ausgabe+'2'; Ausgabe:=Ausgabe+'. Option ausgewählt.'; Application^.Alert(NIL,1,0,Ausgabe,' Ok'); OK:=TRUE END ELSE OK:=FALSE END; FUNCTION TMyDialog.Cancel: BOOLEAN; BEGIN IF Application^.Alert(NIL,2,2,'Wirklich Beenden?', ' Abbruch| Ok')=2 THEN Cancel:=TRUE ELSE Cancel:=FALSE END; BEGIN MyApplication.Init('KLNS','Kleines'); MyApplication.Run; MyApplication.Done END. Wir haben einen großen Teil des letzten Programmes einfach übernehmen können. Wir haben immer noch unser Applikations-Objekt MyApplication, wir haben immer noch das gleiche alte Dialog-Objekt TMyDialog (an OK und Cancel hat sich eigentlich nur geändert, daß wir dort nicht mehr den Befehl zum Beenden des Programms geben). Es hat sich aber auch einiges geändert: Wir haben zwei neue Objekte TOpenDialog und TInfoMenu (beide abgeleitet vom Typ mit den überschriebenen Methoden und TInfoMenu.Work). In TMyApplication.InitInstance ist einiges dazu gekommen, und dafür macht InitMainWindow überhaupt nichts mehr. Ehe wir unsere Menüzeile benutzen können, müssen wir natürlich erst einmal die Resource geladen haben. Wir erinnern uns, daß wir das in der Methode gemacht hatten. Direkt nach dem Laden der Resource können wir dann mit der Installation unseres Menüs loslegen: PROCEDURE TMyApplication.InitInstance; BEGIN LoadResource('KLEINES.RSC',''); LoadMenu(main_menu); NEW(PInfoMenu,Init(@SELF,K_Ctrl,Ctrl_I, menu_info,desk_menu)); NEW(POpenDialog,Init(@SELF,K_Ctrl,Ctrl_D, menu_open_dialog,file_menu)); INHERITED InitInstance; SetQuit(menu_quit,file_menu) END; Der Befehl erklärt sich ja schon fast von selbst. Das einzige, was es dazu noch zu sagen gäbe, ist, daß LoadMenu nicht nur das Menü lädt, sondern auch noch darstellt und mit der Verwaltung beginnt. So wie wir schon im Dialog jedem einzelnen Button ein Objekt zugeordnet hatten, machen wir es jetzt auch mit den einzelnen Menü-Punkten. NEW(PInfoMenu,Init(@SELF,K_Ctrl,Ctrl_I, menu_info,desk_menu)); Das kennen wir ja schon. Wir instantiieren ein neues Objekt (diesmal vom abgeleiteten Typ PInfoMenu von ) und initialisieren es mit dessen Constructor Init. Dabei legen wir fest, daß das Objekt zum Menü-Eintrag menu_info in der Spalte desk_menu gehört (ich setze bei Menü-Einträgen immer ein vorangestelltes "menu_" und bei den Titel ein hintenangestelltes "_menu"). Außerdem soll dieser Menü-Punkt selektiert werden, wenn gedrückt wird. Analog läuft das dann mit dem Objekt POpenDialog. Wenn nun ein Menü-Punkt, der zu einem entsprechenden -Objekt gehört, selektiert wird, dann wird die Methode Work dieses Objektes gestartet. Damit etwas passiert, wenn unsere beiden Menü-Punkte selektiert werden, müssen wir natürlich noch die beiden Methoden und TInfoMenu.Work überschreiben. In die Methode TOpenDialog.Work schieben wir einfach den Inhalt unseres alten InitMainWindow, wir bauen hier also unseren Dialog auf - und diesmal macht die Abfrage, ob der Dialog schon installiert ist, auch Sinn, denn wir können den Menü- Punkt zum Öffnen des Dialog-Fensters mehrmals aufrufen (sogar wenn der Dialog gerade offen ist). Bei der Installation des Dialoges benutzen wir jetzt übrigens die Variable (die zum Objekt TKeyMenu gehört). ADialog ist ein Pointer, der auf ein Dialog-Objekt, daß zu diesem Menü-Eintrag gehört, zeigen soll. Wenn der oberste Menü-Punkt im Desk-Menü selektiert wird, dann soll ein einfacher Dialog (ohne einen einzigen Button - man kann ja einfach das Fenster zumachen, wenn man den Dialog beenden will) aufgerufen werden. Aber das ist ja jetzt ein alter Hut, und deshalb verliere ich darüber auch kein Wort mehr. Wir haben in diesen beiden beiden Beispiel-Programmen keine einzige Abfrage über irgendwelche GEM-Aktionen selber machen müssen. Wir haben bisher nicht mal eine einzige eigene Prozedur geschrieben, sondern nur bestehende Methoden überschrieben. ObjectGEM liefert zu jedem GEM-Element einen eigenen Objekt- Typ, und zu jeder Aktion des Users gibt es eine passende Methode, die dann aufgerufen wird. Wir brauchen uns also nur noch auf das Wesendliche zu konzentrieren, anstatt uns mit dem Event-Loop und der Abfrage von Events rumzuärgern. Die ObjectGEM-Units werden wie gewohnt mit der -Klausel eingebunden. Dabei sollte folgende Reihenfolge eigehalten werden (abgesehen von nicht benötigten Units): uses Objects, OTypes, OProcs, OWindows, OValidat, ODialogs,OStdDlgs, OStdWnds, ODB; Wenn zusätzlich noch andere Units eingebunden werden (z.B. Gem, Tos etc.), sollten diese davor eingebunden werden, es sei denn, die Units greifen auf Teile von ObjectGEM zurück. Mit dem "BubbleHelp"-Hilfesystem kann sehr leicht eine kontextsensitive Hilfe realisiert werden. Dazu kann -, - und -Objekten (und davon abgeleiteten Objekten) in der jeweiligen Init-Methode ein String übergeben werden, der von der Dialogbehandlung ausgewertet wird. Im weiteren braucht dieser Hilfstext nicht weiter beachtet zu werden, einzig interessant ist noch die Methode SetHelp zum nachträglichen Ändern des Textes. Wenn man in einem Dialog den Mauscursor auf ein solches Dialogelement bringt und die rechte Maustaste oder drückt, erscheint an der Mausposition eine Sprechblase mit dem festgelegten Hilfstext. Die Sprechblase bleibt mind. eine halbe Sekunde (ObjectGEM-intern festgelegt) sichtbar, danach kann sie mit einem Mausklick oder einem Tastendruck geschlossen werden. Für die kontextsensitive Hilfe außerhalb von Dialogen steht die Methode zur Verfügung. Dort ist auch der Aufbau der Hilfe-Strings beschrieben. In Zukunft wird es evtl. einen sog. "ständigen Hilfemodus" geben, bei dem eine Sprechblase erscheint, wenn sich der Mauscursor eine gewisse Zeit über einem Dialogelement befindet (wie beim Mac System 7). ObjectGEM legt dafür bereits jetzt den -Cookie an, dessen Wert sich aus der Verzögerung bis zur Aktivierung der Hilfe (unterer Integer, -1=Hilfemodus aus) und der Mindestzeit für die Sichtbarkeit der Sprechblase (oberes Word) zusammensetzt. Die Objekte , und besitzen das Feld Clipboard, das auf ein -Objekt zeigt. Normalerweise gibt es nur ein globales Clipboard-Objekt, falls aber eine Spezialisierung notwendig sein sollte, steht die Methode GetClipboard zur Verfügung. Um auf das Clipboard zugreifen zu können (lesend oder schreibend), muß man es mit OpenClipboard öffnen. Von GetClipboardFilename erhält man eine komplette Pfadangabe incl. Dateinamen für das Klemmbrett - nur die Extension fehlt noch (z.B. C:CLIPBRDSCRAP.). Mit IsClipboardFormatAvailable und GetPriorityClipboardFormat kann man komfortabel nach bestimmten Dateitypen im Klemmbrett suchen, ansonsten kann man nun mit den "normalen" Dateifunktionen auf das Klemmbrett zugreifen. Abschließend muß man das Klemmbrett mit CloseClipboard wieder schließen und damit freigeben. Hat man den Inhalt des Klemmbretts verändert, sollte man vorher noch SetClipboardFormat aufrufen, damit die beim Schließen verschickte SC_CHANGED-Message korrekt gesetzt werden kann. Wichtig: Es kann immer nur ein TClipboard-Objekt Zugriff auf das Klemmbrett haben. Wenn also ein Zugriff immer bereits beim Öffnen scheitert, kann es sein, daß bei einem anderen Clipboard- Objekt das Schließen vergessen wurde. In ObjectGEM ist das Drag&Drop-Protokoll in der Version 1.1 implementiert. Der Drag&Drop-Mechanismus steht nur unter MultiTOS zur Verfügung. Wenn ein Programm Drag&Drop unterstützen soll, müssen zumindest die Methoden DDHeaderReply und DDReadData (bzw. DDReadArgs) überschrieben werden. Das Einlesen der Daten muß in letztgenannter Methode selbst vorgenommen werden. Da während des Drag&Drop- Protokolls der Bildschirm nicht blockiert werden darf, erhält man nach erfolgreicher Kommunikation in der Methode DDFinished die Möglichkeit, die Daten entsprechend auszuwerten. Wenn der Aufbau der Kommunikation nicht unnötig in die Länge gezogen werden soll, muß dafür die Methode DDGetPreferredTypes überschrieben werden, in der man die möglichen Dateitypen einschränken kann. Soll das Programm auch auf den PATH-Parameter positiv antworten, muß DDGetPath effektiv gemacht werden. ObjectGEM stellt eine erweiterte Dialogbehandlung zur Verfügung. Folgende Eigenschaften sind zusätzlich zu den üblichen GEM-Möglichkeiten vorhanden: Der Edit-Cursor kann mit der Maus verschoben werden Folgende Tastenkombinationen stehen in einem Edit-Feld zur Verfügung: geht zum vorherigen Eingabefeld geht zum nächsten Eingabefeld Cursor innerhalb des Feldes bewegen Cursor an Feldanfang Cursor an Feldende Cursor auf erstes Eingabefeld Cursor auf letztes Eingabefeld Zeichen links vom Cursor löschen Zeichen rechts vom Cursor löschen Feld löschen s.u. Jedes Eingabefeld, dem ein -Objekt zugeordnet ist, merkt sich die Position des Edit-Cursors bis zur nächsten Aktivierung. Außerdem kann mit die letzte Änderung rückgängig gemacht werden. Dialogelemente, bei denen ein Buchstabe unterstrichen angezeigt wird, können mit aktiviert werden. -Objekte, bei denen cs_WorkBackground gesetzt ist (das ist die Standard-Einstellung), können auch im Hintergrund bedient werden. Um ein solches Dialogfenster wieder in den Vordergrund zu holen, muß man einen Doppelklick rechts auf den Arbeitsbereich des Fensters ausführen. Modale Dialogekönnen durch Anklicken eines inaktiven Dialogelements (z.B. Text oder der Hintergrund) bei gedrückter linker Maustaste verschoben werden. Bei einem Klick außerhalb eines modalen Dialogs wird dieser um den Mauszeiger zentriert. Befindet sich der Mauscursor über einem Dialogelement, dem ein TControl-Objekt zugeordnet ist (das sollte bei den meisten der Fall sein), kann mit der rechten Maustaste oder mit die sog. aufgerufen werden. Mit cs_WorkBackground können Fenster dazu gebracht werden, daß man sie im Hintergrund bedienen kann (unter allen TOS-Versionen). Dies gilt natürlich nur für den Arbeitsbereich, die Fensterkomponenten können nur im Hintergrund angewählt werden, wenn das Betriebssystem dies unterstützt (z.B. MultiTOS, WINX). Solche Fenster können nur noch durch Anklicken einer Fenster-Komponente (Titelzeile etc.) getoppt werden, oder - dies ist ein ObjectGEM-spezifisches Feature - mit einem Doppelklick rechts im Arbeitsbereich! In den TWindow-Fensterobjekten sind z.Z. folgende Tastatur-Shortcuts vorgesehen (#bedeutet, daß die Taste im Ziffernblock gemeint ist): Wählt alle passenden Elemente im Fenster aus (siehe ) Führt die "Kopieren"-Operation durch (siehe ) Druckt den Fensterinhalt aus (siehe bzw. TTextWindow.Print) Schließt das Fenster Führt die "Einfügen"-Operation durch (siehe ) Wechselt die Fenster der Applikation zyklisch (mit in umgekehrter Reihenfolge) Führt die "Ausschneiden"-Operation durch (siehe ) # Bringt das Fenster auf Maximalgröße # Bringt das Fenster in den Hintergrund (AES 4.0) # Ikonifiziert das Fenster (nur mit ICFS) Führt die "Entfernen"-Operation durch (siehe ) Verläßt das Programm (dies ist eigentlich kein Fenster-Shortcut) Ab AES 4.10 unterstützt ObjectGEM Iconification, d.h. GetStyle liefert zusätzlich den Wert SMALLER zurück, und im Fenster erscheint links neben dem Fuller noch der "Verkleinerungsknopf". Wenn dieser Button angewählt wird, wird das entsprechende Fenster ikonifiziert. Dem Icon-Fenster kann per GetIconTitle ein neuer Titel zugewiesen werden, außerdem wird bei einem Redraw nun die Methode IconPaint aufgerufen. Der Status eines Fensters läßt sich mit IsIconified abfragen. Wenn beim Anklicken des SMALLERs zusätzlich gedrückt wird, wird die gesamte Applikation ikonifiziert, d.h. alle Fenster werden in einem Icon-Fenster zusammengefaßt. Dafür stehen ähnliche Funktionen wie bei einem Fenster zur Verfügung. Wichtig: Hierbei werden die Fenster der Applikation nicht geschlossen, sondern nur rechts so weit über den Bildschirmrand geschoben, daß man sie nicht mehr sieht und der Benutzer keine Aktionen mehr an ihnen durchführen kann. Für die Applikation wird dann ein neues Icon-Fenster geöffnet. Soll in einem ikonifizierten Fenster automatisch ein Icon angezeigt werden, muß aufgerufen werden. Damit auch bei einem Applikations-Icon-Fenster ein Icon erscheint, steht die Methode zur Verfügung. Dialoge übernehmen dieses Icon automatisch, wenn ihnen kein eigenes Icon zugewiesen wird. Ist ein ICFS-Server installiert, so ist Iconification auch unter alten TOS-Versionen möglich. Wird beim Anklicken der CLOSERs gedrückt, wird das Fenster ikonifiziert. Das Verkleinern aller Fenster mit ist aus technischen Gründen (noch) nicht möglich bzw. sinnvoll. In einer späteren Version wird es allerdings auch die ICFS-Iconification mit geben (alle Fenster werden einzeln verkleinert). ObjectGEM liegt der ICFS-Server von Dirk Haun und das ICFS-CPX von John McLoud bei. Ikonifizierte Fenster oder Applikationen erhalten von ObjectGEM nur noch Timer- sowie ausgesuchte Message-Events. Evtl. kann in Zukunft aber ein Flag gesetzt werden, so daß auch in einem Icon-Fenster Aktionen durchgeführt werden können. In den -Menüs ist folgende Tastatursteuerung vorgesehen: Wählt den markierten Eintrag aus Bricht das Popup-Menü ab Bringt die Markierung auf den ersten Eintrag Bringt die Markierung auf den letzten Eintrag Bewegt die Markierung nach oben Bewegt die Markierung nach unten Mit den ObjectGEM-Profile-Routinen können die bei vielen Applikationen vorhandenen INF-Dateien sehr leicht realisiert werden. Sie haben außerdem den Vorteil, daß sie als ASCII-Texte verwaltet werden, so daß sie - wenn nötig - auch "von Hand" verändert werden können. Außerdem werden - wenn die Environmentvariable HOME und das Flag as_UseHomeDir gesetzt ist - diese Konfigurationsdateien an einem zentralen Ort (eben dem User-Home-Verzeichnis) gespeichert, so daß auch eine Multi-User-Umgebung realisierbar ist. Wenn nicht gesetzt ist, werden die Dateien wie gewohnt im Ordner der Applikation angelegt. Ein Profile setzt sich aus Blöcken zusammen. Jeder Block hat eine "Überschrift" (in eckigen Klammern, bei den Profile-Routinen auch mit "Anwendungsname" bezeichnet). Nach diese Überschrift folgen die Schlüsselnamen mit den zugehörigen Werten, Leerzeilen sind nur zum Trennen der Blöcke erlaubt. Kommentare beginnen mit einem Semikolon oder # am Zeilenanfang, Kommentarblöcke werden mit ## eingeschlossen. Ein Eintrag innerhalb eines Profiles muß durch den Anwendungs- und Schlüsselnamen eindeutig bestimmt sein, ansonsten wird nur das erste Vorkommen beachtet. Ein Profile könnte also z.B. so aussehen: ; Das ist ein Kommentar innerhalb eines Profiles # das auch [Block 1] Var_1=Test-Text Var_2=42 ## hier beginnt ein Kommentarblock und in der nächsten Zeile hört er auf ## [nächster Block] Var_2=die hat nichts mit o.g. Variable zu tun Var_3=2147483647 Hallo.Welt=Das ist ein Test! Zum Auswerten eines Profiles stehen Routinen für ganze Zahlen (GetPrivateProfileInt, WritePrivateProfileInt) und für Zeichenketten (GetPrivateProfileString, WritePrivateProfileString) zur Verfügung. Sollen Fließkommazahlen bearbeitet werden, muß man diese in Zeichenketten umwandeln (z.B. mit ftoa, atof). Profiles, die direkt auf einer Datei arbeiten, sind recht langsam, vor allem beim Schreiben. Deshalb besteht die Möglichkeit, ein Profile mit OpenPrivateProfile in den Speicher zu laden, wo die Bearbeitung deutlich schneller ist. Da immer nur ein Profile im Speicher verwaltet werden kann, werden Zugriffe auf andere Profiles weiterhin direkt auf der Platte (bzw. Diskette) durchgeführt. ClosePrivateProfile braucht nicht explizit aufgerufen zu werden, dies geschieht automatisch beim Programmende. Man sollte allerdings nach dem Schreiben von Daten immer die Routine SavePrivateProfile aufrufen, da man z.B. bei Accessories nicht davon ausgehen kann, daß die Applikation verlassen werden kann. Die oben erwähnten Routinen bearbeiten private Profiles, d.h. Applikations-spezifische Konfigurationsdateien. Da es aber auch wünschenswert sein kann, bestimmte Werte systemglobal festzulegen, ist z.Z. eine Datei in der Diskussion, die von allen Applikationen verwendet werden kann. Für diese Datei stehen spezielle Routinen zur Verfügung (GetProfileString etc.). Da die Standardisierung aber noch nicht abgeschlossen ist, kann sich am Namen, Ort, Inhalt etc. der Datei noch etwas ändern. Folgendes sollte bei der Resource-Erstellung für ObjectGEM beachtet werden: Das höherwertige Byte von ob_type (AESOBJECT) darf unter ObjectGEM weder verwendet noch verändert werden! Abgesehen davon, daß es eine Zeit lang unter MultiTOS Probleme mit solchen Programmen gegeben hat, benötigt ObjectGEM dieses Byte für interne Zwecke. Durch den objektorientierten Ansatz und die TControl-Schnittstellenobjekte sollte die Verwendung dieses Bytes allerdings auch nicht nötig sein. Alle mit ObjectGEM verwendeten Resourcen sollten wie folgt sortiert sein (eine entsprechende Option sollte in jedem RCS zu finden sein): 1 2 3 4 5 6 Die korrekte Größe für Dialogelemente, denen später ein TCheckBox-, TRadioButton- oder TTriState-Objekt zugeordnet werden soll, kann wie folgt bestimmt werden: Man nimmt im RCS ein BUTTON-Element und verändert den Text wie gewünscht. An den Text werden allerdings noch drei (bzw. zwei, wenn eine Shortcut-Markierung verwendet wird) Leerzeichen angehängt. Nun wird das BUTTON-Element vom RCS entsprechend lang gezeichnet. Zum Schluß löscht man die Leerzeichen wieder, verändert die Größe des BUTTON-Elements allerdings nicht mehr. Im ObjectGEM-Programm werden die neuen Buttons nun korrekt gezeichnet. Bei den Objekten TCheckBox/TTriState wird der selektierte Zustand normalerweise als Häkchen dargestellt. Wenn in der Resource allerdings das Flag CROSSED gesetzt ist, werden daraus "Ankreuzkästchen". Toolbar-Elemente werden unter neueren TOS-Versionen automatisch mit 3D-Effekten versehen, wenn sie vom Typ G_BOX, G_BOXTEXT, G_BUTTON, G_BOXCHAR oder G_FBOXTEXT sind. Elemente vom Typ G_BOXTEXT oder G_FBOXTEXT sollten mit dem kleinen Zeichensatz sowie den Stati SHADOWED und OUTLINED versehen werden; dadurch haben sie einen Pseudo-3D-Effekt, der ab AES 3.40 automatisch durch den "echten" Effekt ausgetauscht wird. Wenn ein Toolbar-Button nicht mit einem TToolbar-Objekt verknüpft wird (siehe "Toolbars"), muß in ob_state SELECTABLE gesetzt sein. Wenn bei InitResource/LoadResource zwei RSC-Dateien für die unterschiedlichen Auflösungen verwendet werden, muß man daran denken, daß die Indizes der Objekte in beiden Dateien gleich sein müssen, da nur eine Include-Datei verwendet werden kann. ObjectGEM kommt auch mit RSC-Dateien zurecht, in denen das pe_tvalid-Feld verkürzt ist. Die nötigen Zeichen der Maske werden ergänzt. In stehen folgende Zeichen zusätzlich zur Verfügung: "H" für Hexadezimalzahlen: "0".."9", "a".."f", "A".."F" "D" für Dezimalzahlen: "0".."9", "+", "-", ",", "." "+" für Vorzeichen: "+", "-" Fenster-Toolbars bestehen aus ganz normalen Dialog-Bäumen in der Resource-Datei, die in SetupWindow mittels LoadToolbar mit dem Fenster verknüpft werden. Um eine einfach Bearbeitung zu gewährleisten, sollten danach alle Toolbar-Buttons mit -Objekten verknüpft werden, die als Schnittstellenobjekte dienen. Eine andere Möglichkeit sind Anwender-konfigurierbare Toolbars. Dabei kann der spätere Anwender des Programms sich seine Toolbar-Buttons mit einem Resource Construction Set zusammenstellen. Diese Buttons werden nicht mit TToolbar-Objekten verknüpft (der Programmierer kann ja nicht alle Anwenderwünsche berücksichtigen), sondern über den erweiterten Objekttyp mit einem Menüeintrag in der Menüleiste der Applikation. Dieses ist die einzige Situation, in der die Verwendung des höherwertigen Bytes von ob_type unter ObjectGEM gestattet ist!!! Findet der Toolbar-Dispatcher im höherwertigen Byte eine Null vor (das sollte bis jetzt immer der Fall sein), passiert gar nichts. Ist dort allerdings ein Wert ungleich Null eingetragen, wird MNSelected mit eben diesem Wert als Index des gewählten Menüeintrags aufgerufen. Wichtig: Dieser Mechanismus funktioniert auch, wenn TToolbar-Objekte eingesetzt werden, d.h. der Programmierer kann diesen Effekt bewußt ausnutzen. Der Aufruf erfolgt in diesem Fall nach dem Aufruf der Work-Methode. Wenn Anwender-konfigurierbare Toolbars eingesetzt werden, muß der Programmierer dafür sorgen, daß die Indizes der Menüeinträge dokumentiert werden. Außerdem wäre es nett, wenn dem Anwender dann z.B. Mini-Icons für die wichtigsten Funktionen zur Verfügung gestellt würden. ObjectGEM verwendet das XAcc-Protokoll nach der Definition vom 28.11.1992, d.h. auch unter MultiTOS ist die korrekte Protokoll-Behandlung gesichert. Als Programmierer braucht man sich nicht um die Einzelheiten des Protokolls kümmern, sondern man kann direkt das Ergebnis in der XAccList (z.B. per TApplication.FindApplication) auswerten. Die einzig interessante "Verwaltungs"-Routine dürfte TApplication.XAccInsert sein. Die XAcc-Eigenschaften des ObjectGEM-Programms werden in der Methode TApplication.GetXAccAttr festgelegt. Wenn man also besondere Eigenschaften kennzeichnen möchte, muß man diese Methode überschreiben. Man kann dort auch die "Extended names" festlegen, die dann von ObjectGEM automatisch korrekt verschickt werden. Wichtige Methoden für das XAcc-Protokoll sind diejenigen, mit denen ein Datenaustausch durchgeführt werden kann. Dies sind die TApplication-Methoden XAccText, XAccKey, XAccMeta und XAccIMG. Diese Methoden dienen zum Empfangen von Daten; ein Verschicken wird z.Z. von ObjectGEM noch nicht direkt unterstützt. ObjectGEM wertet außerdem das AV-Protokoll aus. Dies geschieht ebenfalls automatisch, und es werden die gleichen Datenstrukturen verwendet. Wie beim XAcc-Protokoll dürfte auch nur die Methode TApplication.AVInsert interessant sein, alle spezifischen AV-Messages werden weiterhin an TApplication.HandleAV weitergeleitet. Ist ein AV-Server vorhanden, befindet sich seine AES-ID im Feld TApplication.AVServer. In den Dialogen sollte so oft wie möglich die "BubbleHelp" unterstützt werden (siehe TControl). Ein Hilfesystem bringt nur dann etwas, wenn es konsequent eingesetzt wird. ObjectGEM unterstützt neue, zu BP 7.0 kompatible Runtime-Errors: Fehler-Nr. Bedeutung 211 Aufruf einer abstrakten Methode ("Call to abstract method") Dieser Fehler wird normalerweise von der Prozedur Abstract ausgelöst und zeigt an, daß Sie einen abstrakten Objekttyp nicht abgeleitet und die entsprechenden Methoden überschrieben haben; TSortedCollection ist ein Beispiel dafür 213 Kollektion-Index außerhalb des gültigen Bereichs ("Index range error") Einer TCollection-Methode wurde ein ungültiger Index übergeben (d.h. zu klein/groß). 214 Kollektion-Überlauf ("Collection overflow") Die Kollektion kann kein neues Element mehr aufnehmen, d.h. der Speicher ist voll. Für viele Fenster-Routinen etc. stellt ObjectGEM "neue" Methoden zur Verfügung, die statt der alten verwendet werden sollten (bzw. müssen); z.B. muß statt wind_calc nun die TWindow-Methode WindCalc aufgerufen werden. Dadurch ist es sauber geschriebenen Programmen dann egal, ob z.B. noch eine Toolbar oder eine Menüleiste im Fenster installiert wird, da ObjectGEM nun für die Verwaltung des Work-Bereichs etc. zuständig ist. alte Funktion "neue" Methode evnt_timer(1,0) appl_yield hline form_alert TApplication.Alert form_dial(FMD_FINISH) TWindow.ForceRedraw Neuzeichnen des Fensters TWindow.WMRedraw TApplication.InvalidateRect Neuzeichnen des Desktops TApplication.DeskRedraw form_do TApplication.ExecDialog (besser TDialog verwenden!) Popup-Menüs TApplication.Popup fsel_input FileSelect fsel_exinput GetFreeString TApplication.GetFString graf_mouse(ARROW) ArrowMouse graf_mouse(BUSYBEE) BusyMouse graf_mouse(M_OFF) HideMouse graf_mouse(M_ON) ShowMouse menu_bar TApplication.LoadMenu TApplication.DrawMenu TApplication.FreeMenu objc_change SetState, GetState, Ändern des Objektstatus Enable, Disable, SetText, GetText, SetCheck, GetCheck, Check, Uncheck, Toggle, Gray rsrc_free TApplication.FreeResource rsrc_gaddr TApplication.GetAddr TApplication.GetFImagePtr TApplication.GetFStringPtr rsrc_load TApplication.LoadResource TApplication.InitResource wind_calc TWindow.WindCalc wind_close TWindow.CloseWindow wind_create TWindow.Create wind_delete TWindow.Destroy alte Funktion "neue" Methode wind_get(WF_CURRXYWH) TWindow.GetCurr wind_get(WF_FULLXYWH) TWindow.GetFull wind_get(WF_WORKXYWH) TWindow.GetWork wind_get(DESK,WF_WORKXYWH) GetDesk wind_open TWindow.OpenWindow wind_set(WF_CURRXYWH) TWindow.SetCurr TWindow.SetWork TWindow.FullSize wind_set(WF_INFO) TWindow.SetSubTitle WindSetInfo wind_set(WF_NAME) TWindow.SetTitle WindSetTitle wind_set(DESK,WF_NEWDESK) TApplication.InstallDesktop TApplication.RemoveDesktop wind_set(WF_TOP) TWindow.Top Programm verlassen TApplication.Quit (geschieht, wenn nicht anders angegeben, beim Schließen eines Fensters automatisch, siehe Beispielprogramme) [15mm] Im globalen Record stehen die aktuellen, für ObjectGEM gültigen VDI-Attribute, die auch von Programmen genutzt werden können. Es ist allerdings nicht sicher, daß dieser Record "bis in alle Ewigkeit" unterstützt wird. Es existiert deshalb zwar die Routine ; Programme sollten nach Möglichkeit aber den Zugriff auf GP vermeiden (im Gegensatz zum bisher Dokumentierten)!!! Die Unit installiert eine neue -Funktion, die bei Fehlschlagen einer Speicheranforderung einen nil-Pointer zurückgibt. wird von OWindows umgelenkt, so daß bei einem außerordentlichen Programmabbruch noch versucht werden kann, ein evtl. angelegtes Applikations-Objekt freizugegeben. Wenn SpeedoGDOS installiert ist, werden die Speedo-Fehlermeldungen mittels vst_error so umgeleitet, daß diese nicht mehr auf dem Bildschirm angezeigt werden, sondern mit ChkSpeedoError abgefragt werden können. Ist MiNT oder MultiTOS aktiv, lenkt TApplication.InitGEM die Signale SIGTERM und SIGQUIT auf einen eigenen Handler um, damit die Applikation korrekt verlassen werden kann. Wenn appl_getinfo vorhanden ist, wird diese Auskunftsfunktion verwendet, um spezielle Systemeigenschaften zu ermitteln (so wird die Mag!C-Anpassung realisiert). Für das Vorhandensein der Routine werden AES- bzw. Mag!C-Version getestet sowie die ?AGI- Methode unterstützt (appl_find('?AGI')=0). Ist MultiTOS vorhanden, wird zur Clipboard-Blockierung das AES-interne -Semaphor verwendet. Wenn Let'em Fly installiert ist, wird die Dialog-Flugroutine sowie die Routine beim Klick außerhalb des Dialogs für modale Dialoge verwendet. Der -Cookie (Virtual Screen) wird beachtet. WINX ab Version 2.2 wird direkt unterstützt, z.B. durch die WMArrowed-Methode (Scrollboxen). Die GEM-Message GO_PRIVATE ($1235) wird intern mit folgenden Sub-Opcodes in msg[3] verwendet: GOP_GETVERSION 0 dient als Aufforderung, eine GOP_VERSION-Message zu schicken GOP_TOOLBAR 1 siehe TToolbar.TestMessage GOP_SETQUIT 2 wird von LoadMenu verschickt, um den Menüeintrag (msg[4]) und -titel (msg[5]) für das -Objekt zu setzen; beim Empfang dieser Message ruft MUMesag die Methode SetQuit auf GOP_VERSION $7fff wird als Antwort auf GOP_GETVERSION verschickt; in msg[4] erhält man die jeweilige GOVersion ObjectGEM setzt die Ideen von ObjectWindows für BorlandPascal unter Windows für das Atari-GEM um. Abgesehen von offensichtlichen Unterschieden (z.B. beim Event-Handling) gibt es aber auch noch andere, die hier besprochen werden sollen. In ObjectGEM sind die meisten Methoden virtuell, wodurch es besser möglich sein sollte, in den Programmablauf - wenn nötig - einzugreifen. Außerdem wird in ObjectGEM recht wenig vom Typ PChar Gebrauch gemacht. Dies dient zum einen zur einfacheren Programmierung (normale Strings reichen meistens aus), zum anderen gab (und gibt) es offensichtlich Probleme mit den nullterminierten Strings und der zugehörigen Unit. Im folgenden sind Routinen aufgelistet, die zwar nicht 100% kompatibel, aber zumindest recht ähnlich sind: ObjectWindows/Windows ObjectGEM BringWindowToTop TWindow.Top CheckDlgButton SetCheck GetActiveWindow TApplication.GetPTopWindow GetClientRect TWindow.GetWork GetDesktopWindow DESK GetVersion GEMVersion MiNTVersion TOSVersion GetWindowRect TWindow.GetCurr IntersectRect rc_intersect MapVirtualKey MapKey MessageBox TApplication.Alert PostQuitMessage TApplication.Quit Yield appl_yield "Objektorientierte Programmierung: Philosophie des Programmierens, die von einer Welt ausgeht, die aus gleichberechtigten und einheitlich erscheinenden Objekten besteht..." Das sagt zumindest der Duden "Informatik". Und wer das jetzt sofort und uneingeschränkt verstanden hat, sollte gar nicht mehr weiterlesen, denn er (oder sie) wird am folgenden keinen Spaß, geschweige denn irgend eine wichtige Information finden. Was nun aber ist OOP wirklich? Normalerweise wird OOP nicht konkret definiert, sondern vielmehr durch Beispiele erklärt und mit Metaphern umschrieben. Und so wollen auch wir uns diesem mysteriösen Begriff ein wenig nähern. Normalerweise fangen alle Erklärungsversuche jetzt an, eine Objekthierarchie von Grafikelementen aufzustellen (Werte, Punkte, Linien...). Es gibt aber auch einen interessanteren Ansatz. Wieviele verschiedene Obstsorten haben Sie gerade bei sich in der Küche? Sicherlich eine ganze Menge. Und all diese Sorten lassen sich schön übersichtlich in verschiedene Klassen einteilen (Südfrüchte, Beerenfrüchte, Kernobst, bestrahltes Obst, gespritztes Obst...). Man kann aber auch etwas ganz anderes damit machen. Für 6 Personen 750g gemischtes Obst (Birnen, Nektarinen, Aprikosen, Erd- und Johannisbeeren) 2EL Ahornsirup 2cl Aprikosenlikör 1 Vanilleschote 50g weiche Butter 50g Puderzucker 1 Ei, Salz 100g Mehl 1-2EL Milch 2 Eigelb 1/8l Marsalawein 1EL Zitronensaft [2mm] Das Obst waschen, abtrocknen, zerkleinern und mit Sirup sowie Likör mischen. Das Vanillemark aus der Schote schaben und mit Butter, Puderzucker, Ei, 1 Prise Salz, Mehl und Milch zum dünnflüssigen Teig verrühren. Diesen sofort zu 6 Plätzchen ( 12cm) auf Backpapier streichen und im 200 Grad (Gas: Stufe 3) heißen Ofen in 12-15 Minuten goldgelb werden lassen. Noch heiß über umgestülpten Gläsern rund formen. Eigelb mit Marsala und dem Zitronensaft im heißen Wasserbad schaumig schlagen. Den Obstsalat in die kalten, zu Schälchen geformten Plätzchen füllen und mit der Weinschaumsauce überziehen. Fertig! Sei nun die Folge der Kalorien. Diese kann dann wesentlich einfacher mit berechnet werden. Nun ja, zugegeben, soooo viel haben wir über OOP in diesem Kapitel nicht erfahren, aber der Obstsalat schmeckt wirklich gut! meyer Bertrand Meyer, Objektorientierte Softwareentwicklung, Hanser, Wien; Prentice Hall, London (1990) profi Jankowski, Rabich, Reschke, Atari Profibuch, 10. Auflage, SYBEX, D"usseldorf (1992) compendium Scott Sanders, The ATARI Compendium, SDS Publishing (1993) geiss Dieter Geiß, Jürgen Geiß, Vom Anfänger zum GEM-Profi, Hüthig Buch Verlag, Heidelberg (1990) NVDI Sven Behne, Wilfried Behne, NVDI-Dokumentation, BELA falcon Hendricks, Herzlinger, Pittelkow, Das Buch zum Atari Falcon030, 1. Auflage, Data Becker, Düsseldorf (1992) intern Bär, Bauder, Windows 3.1 intern, 1. Auflage, Data Becker, Düsseldorf (1992) tpwow Ertl, Machholz, TurboPascal für Windows - ObjectWindows, SYBEX, Düsseldorf (1992) borland1 BorlandPascal 7.0, ObjectWindows Programmierhandbuch, Borland (1992) borland2 Borland C++ 4.0, ObjectWindows Referenzhandbuch, Borland (1993) borland3 Paradox 4.0, PAL-Programmierhandbuch, Borland (1992) formate Günter Born, Referenzhandbuch Dateiformate, 2. Auflage, Addison-Wesley, Bonn (1992) formate2 Günter Born, Dateiformate Programmierhandbuch, Addison-Wesley, Bonn (1993) latex Helmut Kopka, : eine Einführung, 4. Auflage, Addison-Wesley, Bonn (1992) gkp Graham, Knuth, Patashnik, Concrete Mathematics, 7. Auflage, Addison-Wesley (1991) duden Hermann Engesser (Hrsg.), Duden Informatik, 2. Auflage, Dudenverlag, Mannheim (1993) kochen meine Familie & ich, Kochen & backen mit Obst, Burda (1991) adams Douglas Adams, Per Anhalter durch die Galaxis; Das Restaurant am Ende des Universums; Das Leben, das Universum und der ganze Rest; Macht's gut und danke für den Fisch; Dirk Gently's Holistische Detektei, Der lange, dunkle Fünfuhrtee der Seele; The Hitch Hiker's Guide to the Galaxy; The Restaurant at the End of the Universe; Life, the Universe and Everything; So Long, and Thanks for all the Fish; Mostly Harmless; Dirk Gently's holistic Detective Agency; The long dark Tea-Time of the Soul; The Meaning of Liff tee Adrian, Temming, Vollers, Das Teebuch, VMA Verlag, Wiesbaden (1989) johnnie Walker, Red Label, John Walker & Sons, Kilmarnock (Müller lebt!) camouflage Camouflage, Bodega Bohemia, Metronome (1993) amos Tori Amos, Under the Pink, eastwest (1994) neworder New Order, Republic, CentreDate (1993)